Blockchain-based data verification method and apparatus, and electronic device

ABSTRACT

One or more implementations of the present specification relate to data verification methods and apparatuses, and electronic devices. A data identifier of target data published by a data provider in a blockchain is obtained, by a verification client device, wherein the data identifier indicates a storage location of the target data in the blockchain. It is determined that the target data is stored in the blockchain based on the data identifier. In response, the target data is obtained, by the verification client device, from the storage location indicated by the data identifier, wherein the target data stored in the blockchain includes verification information to authenticate of the target data. The obtained target data is authenticated, by the verification client device, based on the verification information. A verification result is displayed to a data verifier of the verification client device.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of PCT Application No.PCT/CN2019/080021, filed on Mar. 28, 2019, which claims priority toChinese Patent Application No. 201810713248.0, filed on Jun. 29, 2018,and each application is hereby incorporated by reference in itsentirety.

TECHNICAL FIELD

One or more implementations of the present specification relate to theblockchain field, and in particular, to data verification methods andapparatuses, and electronic devices.

BACKGROUND

A blockchain technology, also referred to as a distributed ledgertechnology, is a new technology in which a plurality of computingdevices participate in “accounting” to maintain a complete distributeddatabase. The blockchain technology has been widely used in many fieldsbecause of its features such as decentralization, openness andtransparency, and participation of each computing device in recordingdata in a database, and fast data synchronization among computingdevices.

SUMMARY

The present specification provides a blockchain-based data verificationmethod, including: obtaining a data identifier of target data publishedby a data provider in a blockchain, where the data identifier indicatesa storage location of the target data in the blockchain; determiningwhether the target data has been stored in the blockchain based on thedata identifier; if the target data has been stored in the blockchain,obtaining the target data from the storage location indicated by thedata identifier, where the target data stored in the blockchain carriesverification information used to verify authenticity of the target data;and verifying authenticity of the obtained target data based on theverification information, and outputting a verification result to a dataverifier.

Optionally, the target data published by the data provider carries agraphic code generated based on the data identifier; and obtaining adata identifier of target data published by a data provider in ablockchain includes: scanning and parsing the graphic code to obtain thedata identifier of the target data in the blockchain.

Optionally, the data identifier is a transaction hash value of atransaction of the target data; and determining whether the target datahas been stored in the blockchain based on the data identifier includes:performing Simplified Payment Verification (SPV) for the transactionbased on a transaction hash value of the transaction of the target data,to determine whether the transaction has been stored in the blockchain.

Optionally, verifying authenticity of the obtained target data based onthe verification information includes: executing an installedverification program to verify authenticity of the obtained target databased on the verification information; or invoking a smart contractpublished in the blockchain, executing a verification program defined inthe smart contract, and verifying authenticity of the obtained targetdata based on the verification information.

Optionally, the target data stored in the blockchain further includesauxiliary information related to the authenticity verification; and theverification information is a hash value obtained by performing a hashcalculation based on original content of the target data and theauxiliary information; and verifying authenticity of the obtained targetdata based on the verification information includes: performing a hashcalculation on the original content of the target data and the auxiliaryinformation to obtain a hash value; determining whether the calculatedhash value is the same as a hash value carried in the target data storedin the blockchain; and if yes, determining that the obtained target datapassed the authenticity verification, or if not, determining that theobtained target data has failed to pass the authenticity verification.

Optionally, the auxiliary information includes any one of or acombination of at least two of the following: an identifier of a datauploader; an upload timestamp of the target data; or an upload locationof the target data.

Optionally, the method includes the following steps: outputting thetarget data obtained from the storage location indicated by the dataidentifier to the data verifier, so that the data verifier compares theoutputted target data with the target data published by the dataprovider.

The present specification further provides a blockchain-based dataverification apparatus, including: a first acquisition module,configured to obtain a data identifier of target data published by adata provider in a blockchain, where the data identifier indicates astorage location of the target data in the blockchain; a determiningmodule, configured to determine whether the target data has been storedin the blockchain based on the data identifier; a second acquisitionmodule, configured to: if the target data has been stored in theblockchain, obtain the target data from the storage location indicatedby the data identifier, where the target data stored in the blockchaincarries verification information used to verify authenticity of thetarget data; and a verification module, configured to: verifyauthenticity of the obtained target data based on the verificationinformation, and output a verification result to a data verifier.

Optionally, the target data published by the data provider carries agraphic code generated based on the data identifier; and the firstacquisition module is configured to: scan and parse the graphic code toobtain the data identifier of the target data in the blockchain.

Optionally, the data identifier is a transaction hash value of atransaction of the target data; and the determining module is configuredto: perform SPV for the transaction based on a transaction hash value ofthe transaction of the target data, to determine whether the transactionhas been stored in the blockchain.

Optionally, the verification module is configured to: execute aninstalled verification program to verify authenticity of the obtainedtarget data based on the verification information; or invoke a smartcontract published in the blockchain, execute a verification programdefined in the smart contract, and verify authenticity of the obtainedtarget data based on the verification information.

Optionally, the target data stored in the blockchain further includesauxiliary information related to the authenticity verification; and theverification information is a hash value obtained by performing a hashcalculation based on original content of the target data and theauxiliary information; and the verification module is further configuredto: perform a hash calculation on the original content of the targetdata and the auxiliary information to obtain a hash value; determinewhether the calculated hash value is the same as a hash value carried inthe target data stored in the blockchain; and if yes, determine that theobtained target data passed the authenticity verification, or if not,determine that the obtained target data has failed to pass theauthenticity verification.

Optionally, the auxiliary information includes any one of or acombination of at least two of the following: an identifier of a datauploader; an upload timestamp of the target data; or an upload locationof the target data.

Optionally, the second acquisition module is further configured to:output the target data obtained from the storage location indicated bythe data identifier to the data verifier, so that the data verifiercompares the outputted target data with the target data published by thedata provider.

The present specification further provides an electronic device,including: a processor; and a memory, configured to store machineexecutable instructions; where by reading and executing the machineexecutable instructions that are stored in the memory and thatcorrespond to a control logic for blockchain-based data verification,the processor is enabled to: obtain a data identifier of target datapublished by a data provider in a blockchain, where the data identifierindicates a storage location of the target data in the blockchain;determine whether the target data has been stored in the blockchainbased on the data identifier; if the target data has been stored in theblockchain, obtain the target data from the storage location indicatedby the data identifier, where the target data stored in the blockchaincarries verification information used to verify authenticity of thetarget data; and verify authenticity of the obtained target data basedon the verification information, and output a verification result to adata verifier.

According to the previously described technical solution, on one hand,it is determined, based on the data identifier published by the dataprovider, whether the target data has been stored in the blockchain, andauthenticity of the information published by the data provider can beverified, so that the data verifier can quickly identify a false dataidentifier that is published by the data provider and that does notcorrespond to any data storage record in the blockchain.

On the other hand, after it is determined that the target data has beenstored in the blockchain, authenticity verification is performed on thetarget data in the blockchain based on the verification informationcarried in the target data stored in the blockchain, so that the dataverifier can determine whether the content of the target data in theblockchain has been tampered with, and quickly identify abnormal data.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 is a schematic diagram illustrating a blockchain-based dataverification method, according to an example implementation;

FIG. 2 is a diagram illustrating a consortium blockchain, according toan example implementation;

FIG. 3 is a schematic structural diagram illustrating an electronicdevice, according to an example implementation; and

FIG. 4 is block diagram illustrating a blockchain-based dataverification apparatus, according to an example implementation.

DESCRIPTION OF IMPLEMENTATIONS

As the level of social digitalization increases, how to connect the realworld and the digital world has become a key concern when the Internetgoes deeper into more fields of life and industries.

For example, in a typical scenario, some products are sold on ane-commerce website, and because the users can only see some pictures(digital information) on the website, it is necessary to convinceconsumers that the digital information corresponds to a product in thereal world in actual applications.

In view of this, the present specification provides a technical solutionto verify authenticity of the digital information stored in thedistributed database of the blockchain.

During implementation, a standard data storage format can be defined forthe target data, and the target data is uploaded by the uploading clientto the blockchain node device accessible by the uploading clientaccording to the defined data storage format. The defined data storageformat can include verification information used to verify authenticityof the target data.

After receiving the target data uploaded by the uploading client, thenode device can publish the target data in the blockchain, and store thetarget data in the distributed database of the blockchain after theconsensus processing among the node devices in the blockchain.

After the target data is successfully stored in the distributed databaseof the blockchain, the node device in the blockchain can return a dataidentifier indicating the storage location of the target data in theblockchain to the data provider through the uploading client. Forexample, in actual applications, the data identifier can specifically bea transaction hash value of a transaction of the target data.

Further, after the target data is successfully stored in the distributeddatabase of the blockchain, the data provider can publish the targetdata and the data identifier of the target data in the blockchainreturned by the node device in the blockchain, for example, through awebsite.

After viewing the target data published by the data provider and thedata identifier of the target data in the blockchain, the data verifiercan verify, through the verification client, authenticity of the targetdata published by the data provider.

First, the verification client can obtain the data identifier publishedby the data provider, and verify, based on the data identifier, whetherthe target data has been stored in the distributed database of theblockchain.

Further, if it is verified that the target data has been stored in thedistributed database of the blockchain, the target data stored in theblockchain can be obtained from the storage location indicated by thedata identifier, and then authenticity verification is performed on thetarget data based on the verification information carried in the targetdata, and a verification result is output to the data verifier by theverification client.

According to the previously described technical solution, on one hand,it is determined, based on the data identifier published by the dataprovider, whether the target data has been stored in the blockchain, andauthenticity of the information published by the data provider can beverified, so that the data verifier can quickly identify a false dataidentifier that is published by the data provider and that does notcorrespond to any data storage record in the blockchain.

On the other hand, after it is determined that the target data has beenstored in the blockchain, authenticity verification is performed on thetarget data in the blockchain based on the verification informationcarried in the target data stored in the blockchain, so that the dataverifier can determine whether the content of the target data in theblockchain has been tampered with, and quickly identify abnormal data.

The following describes the present specification by using theimplementations and with reference to the specific applicationscenarios.

Referring to FIG. 1, FIG. 1 illustrates a blockchain-based dataverification method, according to an implementation of the presentspecification. The method is applied to a verification client in ablockchain and includes the following steps:

Step 102: Obtain a data identifier of target data published by a dataprovider in a blockchain, where the data identifier indicates a storagelocation of the target data in the blockchain.

Step 104: Determine whether the target data has been stored in theblockchain based on the data identifier.

Step 106: If the target data has been stored in the blockchain, obtainthe target data from the storage location indicated by the dataidentifier, where the target data stored in the blockchain carriesverification information used to verify authenticity of the target data.

Step 108: Verify authenticity of the obtained target data based on theverification information, and output a verification result to a dataverifier.

The target data can specifically include any form of digital informationthat can be stored in a blockchain, that can be released through theInternet, and that corresponds to an object in the real world.

For example, in one scenario, the target data can specifically be aproduct quality inspection report issued by a brick-and-mortar qualityinspection organization, and the merchant can release a picture of theproduct together with a picture of the product quality inspection reportof the product when issuing the product through an electronic commerceplatform.

The data identifier can specifically include any form of identificationinformation indicating a storage location of the data stored in theblockchain.

For example, in an illustrated implementation, in a distributed databaseof a blockchain, data is typically recorded in a transaction, stored ina block in the blockchain, and the transaction stored in the block istypically organized into a Merkle tree based on the transaction hashvalue of the transaction. Therefore, to facilitate data retrieval, thedata identifier can specifically be a transaction hash value of atransaction of data. The transaction of the data can be quickly locatedbased on a transaction hash value. Of course, in actual applications,the data identifier can specifically be a transaction index of atransaction of the data.

The blockchain described in the present specification can specificallyinclude any type of blockchain network.

For example, in an illustrated implementation, the blockchain canspecifically be a consortium blockchain including a plurality ofmerchants, a plurality of quality inspection organizations, and aplurality of consumers. As a data uploader, the quality inspectionorganization can access any node device in the consortium blockchainthrough the uploading client, and upload the product quality inspectionreport to the node device in the form of digital information. The nodedevice initiates consensus processing for the product quality inspectionreport in the blockchain, and stores the product quality inspectionreport in the distributed database of the blockchain after the consensusis passed. As a data provider, a merchant can release, through anelectronic commerce platform, a product quality inspection report issuedby a quality inspection organization. When viewing the product qualityinspection report released by the merchant, the consumer can alsoinitiate authenticity verification for the product quality inspectionreport by accessing any node device in the consortium blockchain throughthe verification client.

The following describes the technical solution of the presentspecification in detail based on an example in which the target data isa product quality inspection report, the blockchain is the previouslydescribed consortium blockchain including a plurality of merchants, aplurality of quality inspection organizations, and a plurality ofconsumers.

Referring to FIG. 2, FIG. 2 is a diagram illustrating a consortiumblockchain, according to the present specification.

As shown in FIG. 2, a blockchain operator can pre-establish a consortiumblockchain including a plurality of node devices. Merchants, productquality inspection organizations, and consumers can register in theconsortium blockchain, and access the consortium blockchain as membersof the consortium blockchain after obtaining legal identities in theconsortium blockchain (for example, obtaining private key/public keypairs assigned by the consortium blockchain).

A specific process in which a merchant, a product quality inspectionorganization, and a consumer are registered in a consortium blockchainand join the consortium blockchain as members of the consortiumblockchain is omitted in the present specification for simplicity.

Referring to FIG. 2, as a data uploader, the product quality inspectionorganization can access a node device in a consortium blockchain throughan uploading client, and upload a product quality inspection reportissued for a product entrusted by a merchant to the node device in theform of digital information.

As a data verifier, a consumer can access a node device in a consortiumblockchain through a verification client. When viewing a product qualityinspection report released by a merchant, the consumer can initiateauthenticity verification for the product quality inspection reportthrough the verification client.

It is worthwhile to note that the uploading client and the verificationclient each can be a web client (such as a blockchain browser) or apre-installed application (APP), which is not specifically limited inthe present specification.

In the present specification, the product quality inspectionorganization can define a standard data storage format for a productquality inspection report to be uploaded. After the product qualityinspection organization issues a product quality inspection report forthe product entrusted by the merchant, the product quality inspectionreport can be organized into a standard data storage format, signedbased on the private key held by the product quality inspectionorganization, and then uploaded to the blockchain node device accessibleby the uploading client.

The data storage format defined for the product quality inspectionreport can include three parts: original content of the data,verification information, and auxiliary information. The verificationinformation is specifically used to verify authenticity of the data. Theauxiliary information can be an auxiliary parameter related to theauthenticity verification.

In an illustrated implementation, the verification information can be ahash value obtained by performing a hash calculation based on theoriginal content of the product quality inspection report and theauxiliary information. The auxiliary information can include one of or acombination of at least two of the following: an identity of a datauploader, an upload timestamp, an upload location, etc.

In this case, the data storage format defined for the product qualityinspection report can be shown in Table 1.

TABLE 1 Number Field name Field content 1 Content field Original contentof data 2 Uploader identity field Identity of an uploader 3 Upload timefield Upload timestamp of the data 4 Upload location field Uploadlocation of the data 5 Verification information field A hash valuecalculated based on fields 1-4

The specific form of the content field entry is not specifically limitedin the present specification. For example, it can be in the form of apicture.

The uploader identity field entry can be any form of informationindicating the identity of the uploader, for example, an identity cardnumber, fingerprint information, or a digital certificate signature.

The upload time field entry should be based on the generally acceptedworld time, so as to prevent ambiguity caused by inconsistency inunderstanding the same time between people in different time zones. Forexample, people in the Beijing time zone and people in the New York timezone may have inconsistent understanding of the same time.

The address description in the upload location field should not causeambiguity. For example, there is “Zhongshan Road” in many cities. Themost appropriate way is to use unambiguous address expression such aslongitude and latitude coordinates, GeoHash, etc.

In the present specification, after receiving the product qualityinspection report uploaded by the uploading client, the node device inthe consortium blockchain can first verify the signature of the productquality inspection report based on the public key corresponding to theprivate key held by the product quality inspection organization. If thesignature verification is passed, it indicates that the product qualityinspection report is the information uploaded by the legitimate productquality inspection organization. In this case, the target data can bepublished in the blockchain, and the product quality inspection reportcan be stored in the distributed database of the blockchain after theconsensus processing among the node devices in the consortium blockchainis complete.

The consensus algorithm used in the consortium blockchain is notspecifically limited in the present specification. For example,mainstream consensus algorithms suitable for use in a consortiumblockchain, such as PBFT, can be used, or a related consensus algorithmcan be independently developed by the operator of the consortiumblockchain.

When the product quality inspection report is successfully stored in thedistributed database of the blockchain, the node device in theblockchain can return a data identifier indicating the storage locationof the product quality inspection report in the blockchain to theproduct quality inspection organization through the uploading client.

For example, in an illustrated implementation, the data identifier canspecifically be a transaction hash value of a transaction of the productquality inspection report.

In the present specification, the product quality inspectionorganization can also send the generated product quality inspectionreport and the data identifier returned by the node device in theconsortium blockchain to the merchant. After receiving the productquality inspection report and the data identifier that are sent by theproduct quality inspection organization, the merchant can publish theproduct quality inspection report and the data identifier to a consumerthrough a website. For example, a picture of a product can be publishedto a consumer together with a picture of the product through anelectronic merchant platform.

After viewing the product quality inspection report released by themerchant and the data identifier of the product quality inspectionreport in the blockchain, the consumer can verify authenticity of theproduct quality inspection report released by the merchant through theverification client.

In an illustrated implementation, after viewing the data identifier ofthe product quality inspection report in the blockchain that ispublished by the merchant, the consumer can manually enter the dataidentifier on the user interface provided by the verification client.The verification client can obtain the data identifier manually input bythe user, and then initiate, based on the obtained data identifier,verification of the product quality inspection report.

In another illustrated implementation, when publishing the productquality inspection report, the merchant can add a graphic code (such asa two-dimensional code or a bar code) of the product quality inspectionreport to the released product quality inspection report.

For example, if the data identifier is a transaction hash value of atransaction of the product quality inspection report, the merchant cangenerate a corresponding graphic code by using a character stringcorresponding to the transaction hash value as coding information, andthen attach the generated graphic code to the picture of the releasedproduct quality inspection report.

In this case, the consumer can scan and parse the graphic code by usingthe verification client to obtain the data identifier carried in thegraphic code, and then initiate, based on the parsed data identifier,verification of the product quality inspection report.

In the present specification, after the verification client obtains thedata identifier of the product quality inspection report in theconsortium blockchain that is published by the merchant, it can bedetermined, based on the data identifier, whether the product qualityinspection report has been stored in the distributed database of theconsortium blockchain.

In an illustrated implementation, the data identifier is a transactionhash value of the transaction of the product quality inspection report,and Simplified Payment Verification (SPV) can be performed on thetransaction based on the transaction hash value, to determine whetherthe transaction has been stored in the distributed database of theconsortium blockchain.

SPV is a protocol used to verify whether a transaction already exists inthe distributed database of the blockchain. The following describes indetail a process of performing SPV on the transaction based on thetransaction hash.

In actual applications, a block in a blockchain generally includes twoparts: a block header and a block body (including a transaction). Atransaction recorded in a block is generally organized into a Merkletree in the form of a transaction hash value.

The detailed process of organizing a hash value of a transactionrecorded in a Merkle tree is not specifically limited in the presentspecification. A person skilled in the art can implement the technicalsolution in the present specification by referring to relatedtechnologies.

When SPV is performed on a transaction based on a transaction hashvalue, a Merkle verification path of the transaction including a targetblock of the transaction in a Merkle tree can be obtained first.

The Merkle verification path is specifically a path formed by siblingnodes (that is, neighboring nodes) that are obtained by traversing theMerkle tree based on the transaction value of a transaction. When SPV isperformed on a transaction, the Merkle verification path of thetransaction can be used as a calculation parameter for inverselycalculating a hash value corresponding to the root node of the Merkletree at which the transaction is located.

It is worthwhile to note that the Merkle verification path can bemanually submitted by the user, or can be proactively queried from theblockchain by the verification client.

For example, when the verification client proactively queries the Merkleverification path of the transaction in the Merkle tree including thetarget block of the transaction, the verification client can firstlocate the target block in which the transaction is located based on thetransaction hash value of the transaction.

A process of locating a block in which a transaction is located based ona transaction hash value is omitted in the present specification forsimplicity. For example, in the related art, a Bloom filter can bedeployed to locate a block in which a hash value of a transaction islocated. After locating the block in which the transaction is located,the Merkle verification path of the transaction in the Merkle tree canbe further found from the located Merkle tree of the block.

In the present specification, after obtaining the Merkle verificationpath of the transaction in the Merkle tree including the target block ofthe transaction, the hash value of the block header of the target block(that is, the hash value of the root node of the Merkle tree of thetarget block) can be calculated based on the calculation procedurespecified by the SPV protocol. Then, it can be determined whether thecalculated hash value of the block header of the target block matchesthe hash value stored in the block header of the target block. If thecalculated hash value of the block header of the target block matchesthe hash value stored in the block header of the target block, it can bedetermined that the transaction is included in the target block; thatis, the product quality inspection report has been successfully storedin the distributed database of the consortium blockchain. Alternatively,if the calculated hash value of the block header of the target blockdoes not match the hash value stored in the block header of the targetblock, it indicates that the transaction is not included in the targetblock; that is, the product quality inspection report is notsuccessfully stored in the distributed database stored in the consortiumblockchain.

In the present specification, when it is determined, through thepreviously described implementation process, that the product qualityinspection report has been stored in the distributed database of theconsortium blockchain, the product quality inspection report can befurther obtained from the storage location indicated by the dataidentifier.

For example, if the data identifier is still the transaction hash valueof the transaction of the product quality inspection report, thecorresponding transaction can be located based on the transaction hashvalue, and then the product quality inspection report recorded in thetransaction can be read from the located transaction.

After the product quality inspection report is obtained from the storagelocation indicated by the data identifier, the verification informationcarried in the standard storage format of the product quality inspectionreport can be further read, and then authenticity of the product qualityinspection report obtained from the distributed database of theconsortium blockchain can be verified based on the verificationinformation.

In the present specification, the authenticity verification isspecifically to verify whether the original content recorded in theproduct quality inspection report is tampered with.

For example, in some scenarios, after a product quality inspectionreport is issued by a product quality inspection organization, theproduct quality inspection report can be organized into a standard datastorage format and then sent to a merchant for uploading. In this case,some less reputable merchants can maliciously modify certain fields inthe product quality inspection report before uploading the report.

For another example, in other scenarios, the product quality inspectionreport can be illegally intercepted during transmission, and certainfields in the report can be maliciously modified.

By introducing the process for verifying authenticity of the productquality inspection report in the blockchain, consumers can quicklyidentify malicious modifications of the product quality inspectionreport listed above.

In the present specification, when the verification client verifiesauthenticity of the product quality inspection report obtained from thedistributed database of the consortium blockchain based on theverification information carried in the product quality inspectionreport, the verification client can specifically execute a locallyinstalled verification program, or can implement the verification byremotely invoking a smart contract deployed in the consortiumblockchain.

In an illustrated implementation, a verification program can beinstalled on the verification client to verify authenticity of theproduct quality inspection report.

For example, the authenticity verification rule of the product qualityinspection report can be released by the product quality inspectionorganization serving as a data uploader, and the developer of theverification client can develop corresponding program execution code(for example, a function corresponding to the execution logic of theverification rule) in the software environment of the verificationclient based on the verification rule published by the product qualityinspection organization.

When the verification client determines that the product qualityinspection report has been stored in the distributed database of theconsortium blockchain, and obtains the product quality inspection reportstored in the consortium blockchain, the verification client can readthe verification information from the obtained product qualityinspection report. For example, when the data storage format shown inTable 1 is used, the verification client can read the verificationinformation from field 5 shown in Table 1.

Further, the verification program installed locally can be executed toverify authenticity of the product quality inspection report obtainedfrom the consortium blockchain based on the read verificationinformation.

In an illustrated implementation, a smart contract can alternatively bepre-deployed in the consortium blockchain, and a verification procedurefor verifying authenticity of the product quality inspection report isdefined in the smart contract.

For example, an operator of a consortium blockchain can developcorresponding contract code based on an authenticity verification rulefor the product quality inspection report released by a product qualityinspection organization as a data uploader, deploy a smart contract, andthen publish the smart contract in the consortium blockchain. Then, anode device in the consortium blockchain can perform consensusprocessing on the smart contract, and store the smart contract in adistributed database of the consortium blockchain after the consensusprocessing is complete, so that a client accessing the consortiumblockchain can remotely invoke the smart contract.

When the verification client determines that the product qualityinspection report has been stored in the distributed database of theconsortium blockchain, and obtains the product quality inspection reportstored in the consortium blockchain, the verification client can readthe verification information from the obtained product qualityinspection report, construct a transaction based on the verificationinformation, submit the transaction to the smart contract, initiaterevocation of the smart contract, execute a verification program definedin the smart contract, and verify authenticity of the product qualityinspection report obtained from the consortium blockchain based on theread verification information.

In an illustrated implementation, for example, the verificationinformation is a hash value obtained by performing a hash calculationbased on the original content of the product quality inspection reportand the auxiliary information carried in the data storage format of theproduct quality inspection report. In this case, the verificationprogram installed locally on the verification client is executed; or thesmart contract is invoked remotely, and the verification program definedin the smart contract is executed. When authenticity verification isperformed on the product quality inspection report, the hash value canbe obtained through re-calculation based on the original content of theproduct quality inspection report and the auxiliary information carriedin the data storage format of the product quality inspection reportobtained from the consortium blockchain.

Further, the calculated hash value can be matched with the hash valuethat is carried in the data storage format of the product qualityinspection report as the verification information, to determine whetherthe calculated hash value is the same as the hash value that is carriedin the data storage format of the product quality inspection report asthe check information. If the two are the same, it indicates that thecontent carried in the product quality inspection report stored in theconsortium blockchain is not tampered with, and the product qualityinspection report passes the authenticity verification; of course, ifthe two are different, it indicates that the content carried in theproduct quality inspection report stored in the consortium blockchainhas been tampered with, and the product quality inspection report doesnot pass the authenticity verification.

After the authenticity verification for the product quality inspectionreport is complete, the authenticity verification result can be outputby the verification client to a consumer. Then, the consumer candetermine whether to purchase the product by referring to theauthenticity verification result output by the verification client forthe product quality inspection report.

In the present specification, the product quality inspection reportobtained from the consortium blockchain can also be output to a consumerthrough the verification client, so that the consumer can compare thestored product quality inspection report in the consortium blockchainwith the product quality inspection report released by the merchant.

In this way, the consumer can visually check whether the informationrecorded in the product quality inspection report released by themerchant is consistent with the information recorded in the productquality inspection report uploaded by the product quality inspectionorganization.

In actual applications, the product quality inspection report can beoutput to the consumer immediately after being obtained from theconsortium blockchain; or the product quality inspection report can beselectively outputted to a consumer after the authenticity verificationfor the product quality inspection report is complete and theauthenticity verification result is output to the consumer by theverification client.

For example, when the authenticity verification result indicates thatthe product quality inspection report has passed the authenticityverification, the product quality inspection report obtained from theconsortium blockchain can be output and displayed to the consumer. Onthe contrary, if the product quality inspection report does not pass theauthenticity verification, the product quality inspection report is nolonger output to the consumer. In this way, it is ensured that theconsumer can only view the product quality inspection report that haspassed the authenticity verification.

It is worthwhile to note that the product quality inspection report inthe above implementation is only an example of the target data. Clearly,in actual applications, the target data can alternatively be data inother forms other than the product quality inspection report. When thetarget data is data in another form other than a product qualityinspection report, a person skilled in the art can implement thetechnical solution described in the present specification by referringto the implementation process described in the implementations. Detailsare omitted in the present specification for simplicity.

According to the previously described technical solution, on one hand,it is determined, based on the data identifier published by the dataprovider, whether the target data has been stored in the blockchain, andauthenticity of the information published by the data provider can beverified, so that the data verifier can quickly identify a false dataidentifier that is published by the data provider and that does notcorrespond to any data storage record in the blockchain.

For example, if it is determined, based on the data identifier publishedby the merchant, that no product quality inspection report correspondingto the data identifier is stored in the blockchain, it indicates thatthe data identifier published by the merchant may be a false dataidentifier, that is, the product quality inspection report released bythe merchant may not exist.

On the other hand, after it is determined that the target data has beenstored in the blockchain, authenticity verification is performed on thetarget data in the blockchain based on the verification informationcarried in the target data stored in the blockchain, so that the dataverifier can determine whether the content of the target data in theblockchain has been tampered with, and quickly identify abnormal data.

For example, if the product quality inspection report stored in theblockchain does not pass the authenticity verification, it indicatesthat the product quality inspection report can be illegally tamperedwith before or when the report is uploaded, so that the consumer canquickly identify the abnormality.

Corresponding to the previously described method implementations, thepresent specification further provides an implementation of ablockchain-based data verification apparatus. The implementations of theblockchain-based data verification apparatus in the presentspecification can be applied to an electronic device. The apparatusimplementations can be implemented by using software, hardware, or acombination of software and hardware. The software implementation isused as an example. As a logical apparatus, the apparatus is formed byreading the corresponding computer program instructions in thenon-volatile memory by the processor of the electronic device into thememory for execution. In terms of hardware, FIG. 3 is a diagramillustrating a hardware structure of an electronic device in which ablockchain-based data verification apparatus is located. In addition toa processor, a memory, a network interface, and a non-volatile memoryshown in FIG. 3, the electronic device can generally include otherhardware based on other actual functions of the electronic device.Details are omitted here for simplicity.

FIG. 4 is a logical block diagram illustrating a blockchain-based dataverification apparatus, according to an example implementation of thepresent specification.

Referring to FIG. 4, the blockchain-based data verification apparatus 40can be applied to the electronic device shown in FIG. 3, and includes afirst acquisition module 401, a determining module 402, a secondacquisition module 403, and a verification module 404.

The first acquisition module 401 is configured to obtain a dataidentifier of target data published by a data provider in a blockchain,where the data identifier indicates a storage location of the targetdata in the blockchain.

The determining module 402 is configured to determine whether the targetdata has been stored in the blockchain based on the data identifier.

The second acquisition module 403 is configured to: if the target datahas been stored in the blockchain, obtain the target data from thestorage location indicated by the data identifier, where the target datastored in the blockchain carries verification information used to verifyauthenticity of the target data.

The verification module 404 is configured to: verify authenticity of theobtained target data based on the verification information, and output averification result to a data verifier.

In this implementation, the target data published by the data providercarries a graphic code generated based on the data identifier; and thefirst acquisition module 401 is configured to: scan and parse thegraphic code to obtain the data identifier of the target data in theblockchain.

In this implementation, the data identifier is a transaction hash valueof a transaction of the target data; and the determining module 402 isconfigured to: perform SPV for the transaction based on a transactionhash value of the transaction of the target data, to determine whetherthe transaction has been stored in the blockchain.

In this implementation, the verification module 404 is furtherconfigured to: execute an installed verification program to verifyauthenticity of the obtained target data based on the verificationinformation; or invoke a smart contract published in the blockchain,execute a verification program defined in the smart contract, and verifyauthenticity of the obtained target data based on the verificationinformation.

In this implementation, the target data stored in the blockchain furtherincludes auxiliary information related to the authenticity verification;and the verification information is a hash value obtained by performinga hash calculation based on original content of the target data and theauxiliary information; and the verification module 404 is furtherconfigured to: perform a hash calculation on the original content of thetarget data and the auxiliary information to obtain a hash value;determine whether the calculated hash value is the same as a hash valuecarried in the target data stored in the blockchain; and if yes,determine that the obtained target data passed the authenticityverification, or if not, determine that the obtained target data hasfailed to pass the authenticity verification.

In this implementation, the auxiliary information includes any one of ora combination of at least two of the following: an identifier of a datauploader; an upload timestamp of the target data; or an upload locationof the target data.

In this implementation, the second acquisition module 403 is furtherconfigured to: output the target data obtained from the storage locationindicated by the data identifier to the data verifier, so that the dataverifier compares the outputted target data with the target datapublished by the data provider.

For the detailed implementation process of the functions and purposes ofthe modules in the apparatus, references can be made to theimplementation process of the corresponding steps in the method, anddetails are omitted here for simplicity.

Because the apparatus implementation basically corresponds to the methodimplementation, for the related parts, references can be made to thedescription of the method implementation. The previously describedapparatus implementation is merely an example, where the units describedas separate parts can or does not have to be physically separate, andcomponents displayed as units can or cannot be physical units, and canbe located in one place or can be distributed on a plurality of networkunits. Based on the practical needs, some or all of these modules can beselected to implement the purpose of the present specification. A personof ordinary skill in the art can understand and implement theblockchain-based data processing apparatus without creative efforts.

The system, apparatus, module, or unit illustrated in the previouslydescribed implementations can be implemented by using a computer chip oran entity, or can be implemented by using a product with a certainfunction. A typical implementation device is a computer in the form of apersonal computer, a laptop computer, a cellular phone, a camera phone,a smart phone, a personal digital assistant, a media player, anavigation device, an e-mail transceiver, a game console, a tabletcomputer, a wearable device, or any combination of at least two of thesedevices.

Corresponding to the previously described method implementation, thepresent specification further provides an implementation of anelectronic device. The electronic device includes a processor and amemory configured to store a machine executable instruction, where theprocessor and memory are usually connected to each other through aninternal bus. In other possible implementations, the electronic devicecan also include an external interface used to communicate with otherdevices or components.

In this implementation, by reading and executing the machine executableinstructions that are stored in the memory and that correspond to acontrol logic for blockchain-based data verification, the processor isenabled to: obtain a data identifier of target data published by a dataprovider in a blockchain, where the data identifier indicates a storagelocation of the target data in the blockchain; determine whether thetarget data has been stored in the blockchain based on the dataidentifier; if the target data has been stored in the blockchain, obtainthe target data from the storage location indicated by the dataidentifier, where the target data stored in the blockchain carriesverification information used to verify authenticity of the target data;and verify authenticity of the obtained target data based on theverification information, and output a verification result to a dataverifier.

In this implementation, the target data published by the data providercarries a graphic code generated based on the data identifier; and byreading and executing the machine executable instructions that arestored in the memory and that correspond to a control logic forblockchain-based data verification, the processor is enabled to: scanand parse the graphic code to obtain the data identifier of the targetdata in the blockchain.

In this implementation, the data identifier is a transaction hash valueof a transaction of the target data; and by reading and executing themachine executable instructions that are stored in the memory and thatcorrespond to a control logic for blockchain-based data verification,the processor is enabled to: perform SPV for the transaction based on atransaction hash value of the transaction of the target data, todetermine whether the transaction has been stored in the blockchain.

In this implementation, by reading and executing the machine executableinstructions that are stored in the memory and that correspond to acontrol logic for blockchain-based data verification, the processor isenabled to: execute an installed verification program to verifyauthenticity of the obtained target data based on the verificationinformation; or invoke a smart contract published in the blockchain,execute a verification program defined in the smart contract, and verifyauthenticity of the obtained target data based on the verificationinformation.

In this implementation, the target data stored in the blockchain furtherincludes auxiliary information related to the authenticity verification;and the verification information is a hash value obtained by performinga hash calculation based on original content of the target data and theauxiliary information; and by reading and executing the machineexecutable instructions that are stored in the memory and thatcorrespond to a control logic for blockchain-based data verification,the processor is enabled to: perform a hash calculation on the originalcontent of the target data and the auxiliary information to obtain ahash value; determine whether the calculated hash value is the same as ahash value carried in the target data stored in the blockchain; and ifyes, determine that the obtained target data passed the authenticityverification, or if not, determine that the obtained target data hasfailed to pass the authenticity verification.

In this implementation, by reading and executing the machine executableinstructions that are stored in the memory and that correspond to acontrol logic for blockchain-based data verification, the processor isenabled to: output the target data obtained from the storage locationindicated by the data identifier to the data verifier, so that the dataverifier compares the outputted target data with the target datapublished by the data provider.

A person skilled in the art can easily figure out other implementationsof the present specification after considering and practicing thepresent specification disclosed here. The present specification isintended to cover any variations, usage, or adaptations of the presentspecification that follow the general principles of the presentspecification and include common general knowledge or commonly usedtechnical means in the art that are not disclosed in the presentspecification. The present specification and implementations are merelyexamples. The protection scope and spirit of the present specificationare indicated by the following claims.

It should be understood that the present specification is not limited tothe precise structures described above and illustrated in theaccompanying drawings, and various modifications and changes can be madewithout departing from the scope thereof. The protection scope of thepresent specification should be defined by the appended claims.

The above descriptions are merely preferred implementations of one ormore implementations of the present specification, and are not intendedto limit the present specification. Any modification, equivalentreplacement, improvement, etc., made without departing from the spiritand principles of the present specification shall fall within theprotection scope of the present specification.

What is claimed is:
 1. A computer-implemented method, comprising:obtaining, by a verification client device, a data identifier of targetdata published by a data provider in a blockchain, wherein the dataidentifier indicates a storage location of the target data in theblockchain; determining, by the verification client device, that thetarget data is stored in the blockchain based on the data identifier; inresponse, obtaining, by the verification client device, the target datafrom the storage location indicated by the data identifier, wherein thetarget data stored in the blockchain comprises verification informationto authenticate of the target data; authenticating, by the verificationclient device, the obtained target data based on the verificationinformation; and displaying a verification result to a data verifier ofthe verification client device.
 2. The computer-implemented method ofclaim 1, wherein the target data published by the data providercomprises a graphic code generated based on the data identifier, whereinobtaining the data identifier of the target data published by the dataprovider in the blockchain comprises: scanning and parsing the graphiccode to obtain the data identifier of the target data in the blockchain.3. The computer-implemented method of claim 1, wherein the dataidentifier is a transaction hash value of a transaction of the targetdata; and determining that the target data is stored in the blockchainbased on the data identifier comprises: performing Simplified PaymentVerification (SPV) for the transaction based on the transaction hashvalue of the transaction of the target data, to determine that thetransaction is stored in the blockchain.
 4. The computer-implementedmethod of claim 1, wherein authenticating the obtained target data basedon the verification information comprises: executing an installedverification program to authenticate the obtained target data based onthe verification information; or invoking a smart contract published inthe blockchain, to execute a verification program defined in the smartcontract that performs authentication on the obtained target data basedon the verification information.
 5. The computer-implemented method ofclaim 4, wherein the target data stored in the blockchain furthercomprises auxiliary information related to the authentication; and theverification information is a hash value obtained by performing a hashcalculation based on original content of the target data and theauxiliary information; and authenticating the obtained target data basedon the verification information comprises: performing the hashcalculation on the original content of the target data and the auxiliaryinformation to obtain the hash value; determining whether the calculatedhash value is the same as a hash value comprised in the target datastored in the blockchain; in response to determining that the calculatedhash value is the same as the hash value comprised in the target data,determining that the obtained target data is authenticate; and inresponse to determining that the calculated hash value is not the sameas the hash value comprised in the target data, determining that theobtained target data is not authenticate.
 6. The computer-implementedmethod of claim 5, wherein the auxiliary information comprises any oneof or a combination of at least two of the following: an identifier of adata uploader; an upload timestamp of the target data; or an uploadlocation of the target data.
 7. The computer-implemented method of claim1, further comprising: displaying the target data obtained from thestorage location indicated by the data identifier to the data verifier;and comparing, by the data verifier, the displayed target data with thetarget data published by the data provider.
 8. A non-transitory,computer-readable medium storing one or more instructions executable bya computer system to perform operations comprising: obtaining, by averification client device, a data identifier of target data publishedby a data provider in a blockchain, wherein the data identifierindicates a storage location of the target data in the blockchain;determining, by the verification client device, that the target data isstored in the blockchain based on the data identifier; in response,obtaining, by the verification client device, the target data from thestorage location indicated by the data identifier, wherein the targetdata stored in the blockchain comprises verification information toauthenticate of the target data; authenticating, by the verificationclient device, the obtained target data based on the verificationinformation; and displaying a verification result to a data verifier ofthe verification client device.
 9. The non-transitory, computer-readablemedium of claim 8, wherein the target data published by the dataprovider comprises a graphic code generated based on the dataidentifier, wherein obtaining the data identifier of the target datapublished by the data provider in the blockchain comprises: scanning andparsing the graphic code to obtain the data identifier of the targetdata in the blockchain.
 10. The non-transitory, computer-readable mediumof claim 8, wherein the data identifier is a transaction hash value of atransaction of the target data; and determining that the target data isstored in the blockchain based on the data identifier comprises:performing Simplified Payment Verification (SPV) for the transactionbased on the transaction hash value of the transaction of the targetdata, to determine that the transaction is stored in the blockchain. 11.The non-transitory, computer-readable medium of claim 8, whereinauthenticating the obtained target data based on the verificationinformation comprises: executing an installed verification program toauthenticate the obtained target data based on the verificationinformation; or invoking a smart contract published in the blockchain,to execute a verification program defined in the smart contract thatperforms authentication on the obtained target data based on theverification information.
 12. The non-transitory, computer-readablemedium of claim 11, wherein the target data stored in the blockchainfurther comprises auxiliary information related to the authentication;and the verification information is a hash value obtained by performinga hash calculation based on original content of the target data and theauxiliary information; and authenticating the obtained target data basedon the verification information comprises: performing the hashcalculation on the original content of the target data and the auxiliaryinformation to obtain the hash value; determining whether the calculatedhash value is the same as a hash value comprised in the target datastored in the blockchain; in response to determining that the calculatedhash value is the same as the hash value comprised in the target data,determining that the obtained target data is authenticate; and inresponse to determining that the calculated hash value is not the sameas the hash value comprised in the target data, determining that theobtained target data is not authenticate.
 13. The non-transitory,computer-readable medium of claim 12, wherein the auxiliary informationcomprises any one of or a combination of at least two of the following:an identifier of a data uploader; an upload timestamp of the targetdata; or an upload location of the target data.
 14. The non-transitory,computer-readable medium of claim 8, the operations further comprise:displaying the target data obtained from the storage location indicatedby the data identifier to the data verifier; and comparing, by the dataverifier, the displayed target data with the target data published bythe data provider.
 15. A computer-implemented system, comprising: one ormore computers; and one or more computer memory devices interoperablycoupled with the one or more computers and having tangible,non-transitory, machine-readable media storing one or more instructionsthat, when executed by the one or more computers, perform one or moreoperations comprising: obtaining, by a verification client device, adata identifier of target data published by a data provider in ablockchain, wherein the data identifier indicates a storage location ofthe target data in the blockchain; determining, by the verificationclient device, that the target data is stored in the blockchain based onthe data identifier; in response, obtaining, by the verification clientdevice, the target data from the storage location indicated by the dataidentifier, wherein the target data stored in the blockchain comprisesverification information to authenticate of the target data;authenticating, by the verification client device, the obtained targetdata based on the verification information; and displaying averification result to a data verifier of the verification clientdevice.
 16. The computer-implemented system of claim 15, wherein thetarget data published by the data provider comprises a graphic codegenerated based on the data identifier, wherein obtaining the dataidentifier of the target data published by the data provider in theblockchain comprises: scanning and parsing the graphic code to obtainthe data identifier of the target data in the blockchain.
 17. Thecomputer-implemented system of claim 15, wherein the data identifier isa transaction hash value of a transaction of the target data; anddetermining that the target data is stored in the blockchain based onthe data identifier comprises: performing Simplified PaymentVerification (SPV) for the transaction based on the transaction hashvalue of the transaction of the target data, to determine that thetransaction is stored in the blockchain.
 18. The computer-implementedsystem of claim 15, wherein authenticating the obtained target databased on the verification information comprises: executing an installedverification program to authenticate the obtained target data based onthe verification information; or invoking a smart contract published inthe blockchain, to execute a verification program defined in the smartcontract that performs authentication on the obtained target data basedon the verification information.
 19. The computer-implemented system ofclaim 18, wherein the target data stored in the blockchain furthercomprises auxiliary information related to the authentication; and theverification information is a hash value obtained by performing a hashcalculation based on original content of the target data and theauxiliary information; and authenticating the obtained target data basedon the verification information comprises: performing the hashcalculation on the original content of the target data and the auxiliaryinformation to obtain the hash value; determining whether the calculatedhash value is the same as a hash value comprised in the target datastored in the blockchain; in response to determining that the calculatedhash value is the same as the hash value comprised in the target data,determining that the obtained target data is authenticate; and inresponse to determining that the calculated hash value is not the sameas the hash value comprised in the target data, determining that theobtained target data is not authenticate.
 20. The computer-implementedsystem of claim 15, the operations further comprise: displaying thetarget data obtained from the storage location indicated by the dataidentifier to the data verifier; and comparing, by the data verifier,the displayed target data with the target data published by the dataprovider.